Electronic monitoring and reporting system for discharging judicial obligations

ABSTRACT

This document is related to enhanced tracking and reporting. An example method may comprise receiving an electronic signal associated with an officer account. The example method may comprise receiving, by a processor, historical data associated with at least one parolee account that is associated with the officer account. The example method may comprise automatically displaying a second set of user interface elements comprising a plurality of sections. The example method may comprise displaying user check-in data in a first section of the second set of user interface elements. The example method may comprise displaying user location data in a second section of the second set of user interface elements. The example method may comprise displaying user interface elements to approve or deny pending check-ins in a third section of the second set of user interface elements.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a Continuation of U.S. Non-Provisional applicationSer. No. 17/527,869, titled “ELECTRONIC MONITORING AND REPORTING SYSTEMFOR DISCHARGING JUDICIAL OBLIGATIONS,” filed on Nov. 16, 2021, which isa Continuation-in-Part of U.S. Non-Provisional application Ser. No.17/061,557, titled “ELECTRONIC MONITORING AND REPORTING SYSTEM FORDISCHARGING JUDICIAL OBLIGATIONS,” filed on Oct. 1, 2020. Thatapplication claims the benefit of, and priority to, U.S. ProvisionalPatent Application No. 62/908,606, also titled “ELECTRONIC MONITORINGAND REPORTING SYSTEM FOR DISCHARGING JUDICIAL OBLIGATIONS,” and filed onOct. 1, 2019. Both applications are incorporated by reference herein intheir entirety.

BACKGROUND Field of Art

This disclosure relates to systems and methods for electronicallycommunicating with pretrial defendants, probationers and parolees abouttheir court mandated obligations.

Background

Pretrial defendants who are released from jail pending their hearingsare required to maintain contact with the court by presenting themselvesat scheduled intervals for drug testing, payments and/or court dates.Currently, these individuals are given a written notice from the court,which specifies the various monitoring and reporting obligations thatare placed on the individual.

The various reporting obligations often place a significant burden onthe individual or the defendant who is tasked with these obligations andoften interfere with the defendant's or the individual's other workand/or family obligations. And, as a result, defendants sometimes failto discharge their reporting obligations by failing to report forvarious judicial hearings and other activities. The consequences ofthese failed appearances can range from minor infractions that may bepenalized by the court to imprisonment or the revocation of a parolegrant. Often, these failures subvert the intent of the parole programentirely, which is to rehabilitate offenders and guide them back intosociety while minimizing the likelihood that they will commit a newoffense. Instead, the minor infractions caused by a failure to reportoften cause the parolees to be imprisoned on a technicality, which, atleast according to some studies, tends to increase the rates ofrecidivism.

The various court-mandated reporting obligations also represent asignificant cost for the agencies and governments that must administerthese privileges. For example, probationers and parolees (hereinpretrial defendants, probationers and paroles will be referred tocollectively as probationers) typically report to community supervisionofficers or parole officers (herein referred to as supervision officers)to ensure that they are compliant with the terms of their supervisedrelease. Supervision officers, therefore, often have to track and managea multitude of different reporting dates and obligations for, often,hundreds of probationers. Moreover, the reporting dates and obligationsare often constantly changing as the parolees' obligations are variedfrom one or more court hearings. As such, managing and administering theparolees is often a complicated administrative task for supervisionofficers. Moreover, if the parolees do not appear at the required timeor location, the supervision officer may have to physically track theoffending parolee, which often requires the expenditure of significanttime, cost, and resources.

The current system for tracking the reporting court-mandated obligationsis burdensome for the parolees, a complex and costly endeavor for thegovernments and agencies that administer these obligations, andsometimes subvert the goals of a parole program entirely.

SUMMARY

The present invention overcomes many of the limitations described aboveby making it easy for probationers to comply with court mandatedrequirements and making it easy for supervision officers to administerthe parole process and other court mandated requirements. In oneembodiment of the invention, the system and method described hereinpermits a parolee to receive reminders about his or her court mandatedrequirements. Moreover, the present invention provides a system and amethod for obtaining the specific location of a parolee's mobilecomputing device. This enables parole officers to obtain the parolee'slocation thereby enabling the supervision officer to quickly find theparolee and/or ensure that the parolee has not violated the terms of hisor her parole by visiting areas that are prohibited by a court. Thepresent disclosure also provides a system and a method for ensuring thatthe parolee's mobile computing device does not spoof its location, andto ensure that the mobile computing device that is tracked is in factassociated with the parolee.

In one embodiment, the present invention is for a computer programproduct comprising a non-transitory computer readable storage mediumhaving instructions encoded thereon that, when executed by a processor,causes the processor to receive and store data, and send out notices.More specifically, the present invention is for a computer programproduct that provides a method for supervision officers to inputprobationers' court mandated requirements onto a remote server.Probationers then send their individual device information to a remoteserver. Thereafter, probationers get notifications sent from the remoteserver to their devices reminding them of their court mandated dates.

In one embodiment of the invention, the notification system iseffectuated through an app on the probationer's phone. One benefit ofthe present invention is that by receiving notifications on theirphones, probationers are being reminded of their court dates in a modernway and will be more likely to appear as required. Using this method,eliminates the negative consequences of misplacing paperwork.

In one embodiment of the invention, the remote server sends acommunication to the supervision officer when a notice is sent to theprobationer. One benefit of this is that the supervision officer has arecord of the notifications that are sent and can utilize that data whenmanaging their cases.

In one embodiment of the invention, the supervision officer can manuallyinput all court dates, check-in dates, and drug testing dates into adatabase. The database relates the data to each probationer and theirindividual device. One benefit of this is that the data is all in oneplace and is easy to track for the supervision officer. It can also beupdated easily, and notices can be sent quickly from the remote serverto each probationer as necessary. Providing fast, accurate informationto each probationer provides a higher level of support than is currentlyseen in the industry.

In one embodiment of the invention, after downloading the app, theprobationer takes a picture of himself and sends the picture as well asthe other device information to the remote server. Having a picture ofthe probationer in the database adds another level of verification forthe supervision officer.

In one embodiment of the invention, the location of the probationer'sdevice is stored and monitored on the remote server. The benefit of thisis that the supervision officer can know where the probationer's deviceis at any given time.

In one embodiment, the end user device of the probationer can bemonitored at predetermined periods of time at predetermined frequencies.During these predetermined periods of time, the end user device can bequeried for location information. The benefit of this is that the drainon the end user device is minimized. The drain on the end user devicecan be from a drainage of the battery therein or an exhaustion of a dataplan for the end user device. Furthermore, in various embodiments of thepresent invention it is contemplated that most of the monitoring andadministrative features can be performed at the server side, or by theadministrator's web suite, so as to reduce computing burdens on the enduser device, thereby ensuring that the end user can cheaply and easilyuse most smart phones and other devices without requiring higher endproducts and data plans. In addition, by limiting pinging of the enduser device to certain periods of time, and by not constantly pingingthe end user device, greater efficiency can be achieved.

In one embodiment, the present invention is for a computer implementedmethod for displaying parolee information on a graphical user interface“GUI” of a computer system for enhanced tracking and reporting. Thecomputer implemented method may comprise receiving an electronic signalassociated with an officer account. The electronic signal may beassociated with a first set of user interface elements identifyingmetrics associated with at least one parolee. The first set of userinterface elements may comprise a first section of user interfaceelements that are associated with basic features. The first set of userinterface elements may comprise a second section of user interfaceelements that are associated with geographic features. The first set ofuser interface elements may comprise a third section of user interfaceelements that are associated with identification features. The computerimplemented method may comprise receiving, by a processor, historicaldata associated with at least one parolee account that is associatedwith the officer account. The computer implemented method may compriseautomatically displaying a second set of user interface elementscomprising a plurality of sections. The second set of user interfaceelements may display parolee information associated with the at leastone parolee account that is associated with the officer account. Thecomputer implemented method may comprise displaying user check-in datain a first section of the second set of user interface elements. Thecomputer implemented method may comprise displaying user location datain a second section of the second set of user interface elements. Thecomputer implemented method may comprise displaying user interfaceelements to approve or deny pending check-ins in a third section of thesecond set of user interface elements.

In one embodiment, the computer implemented method may comprisedisplaying a GUI overlay over at least a portion of the second sectionof the second set of user interface elements.

In one embodiment, the portion of the second section of the second setof user interface elements may comprise a map associated with a physicallocation of a user device associated with the at least one paroleeaccount.

In one embodiment, the GUI overlay may be a first color if a thresholdnumber of requirements are met, and a second color if the thresholdnumber of requirements are not met.

In one embodiment, the GUI overlay may comprise green if the thresholdnumber of requirements are met.

In one embodiment, the GUI overlay may comprise red if the thresholdnumber of requirements are not met.

In one embodiment, the threshold number of requirements may comprise anactual check-in time within a threshold timeframe of an expectedcheck-in time.

In one embodiment, the threshold number of requirements may comprise anactual check-in location within a threshold distance of an expectedcheck-in location.

In one embodiment, the threshold number of requirements may compriseactual verification information within a threshold proximity of expectedverification information.

In one embodiment, the verification information may comprise at leastone of a signature, a picture of the parolee taken contemporaneously,and a picture of a location taken contemporaneously.

In one embodiment, the historical data may comprise at least one of aname, a contact address, a profile picture, a contact number, a previouscheck-in expected time, a previous check-in expected location, aprevious check-in actual time, a previous check-in actual location, anda previous check-in photograph.

In one embodiment, the third section of the second set of user interfaceelements may comprise aggregated data.

In one embodiment, the basic features may comprise one or more of acheck-in event, an agenda event, a curfew event, and a time-line event.

In one embodiment, the user check-in data may comprise one or moreentries. Each entry may be associated with a parolee check-in event.

In one embodiment, a score may be associated with each entry in the usercheck-in data.

In one embodiment, engagement of the user interface element to approve apending check-in may cause a score associated with the entry associatedwith the pending check-in to rise.

In one embodiment, engagement of the user interface element to deny apending check-in may cause at least one of a score associated with theentry associated with the pending check-in to lower and a field forreceiving a reason for denial to be prompted.

In one embodiment, the score associated with an entry may be at leastpartially affected by a comparison of an actual check-in time associatedwith the entry with an expected check-in time associated with the entry.

In one embodiment, the score associated with an entry may be at leastpartially affected by a comparison of an actual check-in locationassociated with the entry with an expected check-in location associatedwith the entry.

In one embodiment, the score associated with an entry may be at leastpartially affected by a comparison of actual verification informationassociated with the entry with an expected verification informationassociated with the entry.

Although the description herein discusses applying the present inventionto parolees and court mandated appearances, the invention itself may beapplied to a variety of different use cases including check-ins that maybe required for employment purposes, tracking purposes, biometrics andverification purposes, etc., without departing from the scope of theinvention. For example, the present invention may be used to permitemployees or contractors to check-in when they are at a constructionsite. In other use cases, the present invention may be used to permitdelivery personnel check-into a delivery location and to confirmappropriate delivery of items. In some embodiments, the presentinvention may be used to augment or replace a biometric tracking systemas would be readily understood by persons of ordinary skill in the art.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings illustrate several embodiments and, togetherwith the description, serve to explain the principles of the inventionaccording to the embodiments. It will be appreciated by one skilled inthe art that the particular arrangements illustrated in the drawings aremerely exemplary and are not to be considered as limiting of the scopeof the invention or the claims herein in any way.

FIG. 1 illustrates a system for monitoring parolees in accordance withan exemplary embodiment of the invention.

FIG. 2 illustrates the various modules and sub-modules of the monitoringsystem in accordance with an embodiment of the invention.

FIG. 3 illustrates a flowchart for monitoring a parolee in accordancewith an exemplary embodiment of the present invention.

FIG. 4 illustrates a flowchart for registering a parolee in accordancewith an exemplary embodiment of the present invention.

FIG. 5 illustrates an exemplary interface for defining a securityprofile for a parolee according to an exemplary embodiment of thepresent invention.

FIG. 6 illustrates a flowchart for registering a first curfew for aparolee in accordance with an exemplary embodiment of the presentinvention.

FIG. 7 illustrates a flowchart for updating a security profile for aparolee in accordance with an exemplary embodiment of the presentinvention.

FIG. 8A illustrates an exemplary interface for an agenda for a paroleeto perform according to an exemplary embodiment of the presentinvention.

FIG. 8B illustrates an exemplary interface for an agenda for a paroleeto perform according to an exemplary embodiment of the presentinvention.

FIG. 9 illustrates an exemplary timeline detailing activities or alertsfrom a parolee end user device according to an exemplary embodiment ofthe present invention.

FIG. 10 illustrates one embodiment of components of an example machineable to read instructions from a machine-readable medium and executethem in a processor (or controller).

FIG. 11 illustrates on embodiment of the computing architecture thatsupports an embodiment of the inventive disclosure.

FIG. 12 illustrates components of a system architecture that supports anembodiment of the inventive disclosure.

FIG. 13 illustrates components of a computing device that supports anembodiment of the inventive disclosure.

FIG. 14 illustrates a system for monitoring parolees in accordance withan exemplary embodiment of the invention.

FIG. 15 illustrates the various modules and sub-modules of themonitoring system in accordance with an embodiment of the invention.

FIG. 16 a illustrates a flowchart for monitoring a parolee in accordancewith an exemplary embodiment of the present invention.

FIG. 16 b illustrates another flowchart for monitoring a parolee inaccordance with an exemplary embodiment of the present invention.

FIG. 17 illustrates a graphical user interface (GUI) for monitoring aparolee in accordance with an exemplary embodiment of the presentinvention.

FIG. 18 illustrates a GUI for monitoring a parolee in accordance with anexemplary embodiment of the present invention.

FIG. 19 a illustrates a GUI for monitoring a parolee in accordance withan exemplary embodiment of the present invention.

FIG. 19 b illustrates a GUI for monitoring a parolee in accordance withan exemplary embodiment of the present invention.

DETAILED DESCRIPTION OF EMBODIMENTS

The inventive system and method (hereinafter sometimes referred to moresimply as “system” or “method”) described herein significantly reducesthe resources, time, effort, and costs associated with ensuringcompliance with parolee conditions. Specifically, the inventive systemcollects data from parolees and presents the collected data in an easilydigestible format.

One or more different embodiments may be described in the presentapplication. Further, for one or more of the embodiments describedherein, numerous alternative arrangements may be described; it should beappreciated that these are presented for illustrative purposes only andare not limiting of the embodiments contained herein or the claimspresented herein in any way. One or more of the arrangements may bewidely applicable to numerous embodiments, as may be readily apparentfrom the disclosure. In general, arrangements are described insufficient detail to enable those skilled in the art to practice one ormore of the embodiments, and it should be appreciated that otherarrangements may be utilized and that structural, logical, software,electrical and other changes may be made without departing from thescope of the embodiments. Particular features of one or more of theembodiments described herein may be described with reference to one ormore particular embodiments or figures that form a part of the presentdisclosure, and in which are shown, by way of illustration, specificarrangements of one or more of the aspects. It should be appreciated,however, that such features are not limited to usage in the one or moreparticular embodiments or figures with reference to which they aredescribed. The present disclosure is neither a literal description ofall arrangements of one or more of the embodiments nor a listing offeatures of one or more of the embodiments that must be present in allarrangements.

Headings of sections provided in this patent application and the titleof this patent application are for convenience only and are not to betaken as limiting the disclosure in any way.

Devices that are in communication with each other need not be incontinuous communication with each other, unless expressly specifiedotherwise. In addition, devices that are in communication with eachother may communicate directly or indirectly through one or morecommunication means or intermediaries, logical or physical.

A description of an aspect with several components in communication witheach other does not imply that all such components are required. To thecontrary, a variety of optional components may be described toillustrate a wide variety of possible embodiments and in order to morefully illustrate one or more embodiments. Similarly, although processsteps, method steps, algorithms or the like may be described in asequential order, such processes, methods and algorithms may generallybe configured to work in alternate orders, unless specifically stated tothe contrary. In other words, any sequence or order of steps that may bedescribed in this patent application does not, in and of itself,indicate a requirement that the steps be performed in that order. Thesteps of described processes may be performed in any order practical.Further, some steps may be performed simultaneously despite beingdescribed or implied as occurring non-simultaneously (e.g., because onestep is described after the other step). Moreover, the illustration of aprocess by its depiction in a drawing does not imply that theillustrated process is exclusive of other variations and modificationsthereto, does not imply that the illustrated process or any of its stepsare necessary to one or more of the embodiments, and does not imply thatthe illustrated process is preferred. Also, steps are generallydescribed once per aspect, but this does not mean they must occur once,or that they may only occur once each time a process, method, oralgorithm is carried out or executed. Some steps may be omitted in someembodiments or some occurrences, or some steps may be executed more thanonce in a given aspect or occurrence.

When a single device or article is described herein, it will be readilyapparent that more than one device or article may be used in place of asingle device or article. Similarly, where more than one device orarticle is described herein, it will be readily apparent that a singledevice or article may be used in place of the more than one device orarticle.

The functionality or the features of a device may be alternativelyembodied by one or more other devices that are not explicitly describedas having such functionality or features. Thus, other embodiments neednot include the device itself.

Techniques and mechanisms described or referenced herein will sometimesbe described in singular form for clarity. However, it should beappreciated that particular embodiments may include multiple iterationsof a technique or multiple instantiations of a mechanism unless notedotherwise. Process descriptions or blocks in figures should beunderstood as representing modules, segments, or portions of code whichinclude one or more executable instructions for implementing specificlogical functions or steps in the process. Alternate implementations areincluded within the scope of various embodiments in which, for example,functions may be executed out of order from that shown or discussed,including substantially concurrently or in reverse order, depending onthe functionality involved, as would be understood by those havingordinary skill in the art.

Conceptual Architecture

FIG. 1 illustrates an embodiment of the conceptual architecture for themonitoring system (i.e., checkup system) 120, which, according to anembodiment, may comprise a data request module 122, a notificationcalculator 124 and a mobile device notification interface 126. Themonitoring system 120 is described in greater detail in FIG. 2 , but ingeneral the monitoring system 120 utilizes the judicial data 160 anddata provided by a supervision officer to establish individual userprofiles and notification intervals to keep parolees informed andconfirm their check-in if required. The monitoring system 120 furthercommunicates with the notification system 140 to send notifications toend user devices, such as parolees' mobile computing devices 170.

In addition to the monitoring system 120, the inventive system includesjudicial data 160 which may be provided by the judicial system orsupervision officer about individual parolees. The judicial data, forexample, may comprise information about the parolee and the terms ofparole. It may, for example, comprise information about courtappearances the parolee must make, the check-ins the parolee mustperform and the specific terms of those appearances and/or the specificterms of those requirements, etc. In one embodiment, the monitoringsystem 120 receives the judicial data and calculates check-in andappearance requirements for the parolee.

An administrator's web suites, servers, and computing devices, orsupervision officer's computing device 110, enables a supervisionofficer to input additional information about the parolee and/or theterms of parole. In one embodiment, the supervision officer's computingdevice receives additional information such as the dates of the courtappearances, dates/times of check-ins, permitted geographic locationsand/or permissible radius of travel, etc. In one embodiment, themonitoring system 120 receives the data entered by the supervisionofficer and calculates check-in and appearance requirements for theparolee.

The parolee's mobile computing device 170 receives notifications thatmay be calculated by the monitoring system 120. In one embodiment, theparolee's mobile computing device 170 may display notifications to theparolee and the date/time and/or frequency that may be set by themonitoring system 120 and/or the notification system 140. In oneembodiment, the parolee's mobile computing device 170 may prompt a userto submit his or her current location, which may be obtained from alocation data system 130 and/or the mobile device's 170 operating systemlevel software layer. In addition, the parolee's mobile computing device170 may prompt the parolee to submit a photograph, which may be takencontemporaneously and submitted to the monitoring system 120 withmetadata, such as, but not limited to location data, date and/or timedata, device data, etc.

The notification system 140 interfaces with the monitoring system 120 topush notifications to the parolee's mobile computing device 170. In oneembodiment of the invention, the notification system 140 interface withvarious computing devices and may identify devices by the uniqueidentification number. In one embodiment, the notification system 140functions as a clearing house for delivering communication generated bythe monitoring system 120 and sending them to the parolee's device 170.

The location data system 130 provides location data associated with, anend user device, such as a parolee's mobile computing device 170. Avariety of different location data services may be used, as would beapparent to a person of ordinary skill in the art, without departingfrom the scope of the invention, including, but not limited to GPS,GLONASS, cell phone tower triangulation, etc. In addition, the identityof the end user device can be verified by methods include checking thecell phone number for the end user device, a MAC address for the enduser device, an IMEI number, or a vendor ID for the parolee's device170. Additionally, the location data system can receive mapping datafrom third party vendors such as Google Maps.

Supervision officer's computing device 110 and parolee's mobilecomputing device 170 may be more generally referred to as clientdevice(s) 110 or user device(s) 110. They may include, generally, acomputer or computing device including functionality for communicating(e.g., remotely) over a network 150. Data may be collected from clientdevices 110, and data requests may be initiated from each client device110. Client device(s) 110 may be a server, a desktop computer, a laptopcomputer, personal digital assistant (PDA), an in- or out-of-carnavigation system, a smart phone or other cellular or mobile phone, ormobile gaming device, among other suitable computing devices. Clientdevices 110 may execute one or more client applications, such as a webbrowser (e.g., Microsoft Windows Internet Explorer, Mozilla Firefox,Apple Safari, Google Chrome, and Opera, etc.), or a dedicatedapplication to submit user data, or to make prediction queries over anetwork 150.

In particular embodiments, each user device 110 may be an electronicdevice including hardware, software, or embedded logic components or acombination of two or more such components and capable of carrying outthe appropriate functions implemented or supported by the user device110. For example and without limitation, a user device 110 may be adesktop computer system, a notebook computer system, a netbook computersystem, a handheld electronic device, or a mobile telephone. The presentdisclosure contemplates any user device 110. A user device 110 mayenable a network user at the user device 110 to access network 110. Auser device 110 may enable its user to communicate with other users atother user devices 110.

A user device 110 may have a web browser, such as MICROSOFT INTERNETEXPLORER, GOOGLE CHROME or MOZILLA FIREFOX, and may have one or moreadd-ons, plug-ins, or other extensions, such as TOOLBAR or YAHOOTOOLBAR. A user device 110 may enable a user to enter a Uniform ResourceLocator (URL) or other address directing the web browser to a server,and the web browser may generate a Hyper Text Transfer Protocol (HTTP)request and communicate the HTTP request to server. The server mayaccept the HTTP request and communicate to the user device 110 one ormore Hyper Text Markup Language (HTML) files responsive to the HTTPrequest. The user device 110 may render a web page based on the HTMLfiles from server for presentation to the user. The present disclosurecontemplates any suitable web page files. As an example and not by wayof limitation, web pages may render from HTML files, Extensible HyperText Markup Language (XHTML) files, or Extensible Markup Language (XML)files, according to particular needs. Such pages may also executescripts such as, for example and without limitation, those written inJAVASCRIPT, JAVA, MICROSOFT SILVERLIGHT, combinations of markup languageand scripts such as AJAX (Asynchronous JAVASCRIPT and XML), and thelike. Herein, reference to a web page encompasses one or morecorresponding web page files (which a browser may use to render the webpage) and vice versa, where appropriate.

The user device 110 may also include an application that is loaded ontothe user device 110. The application 110 obtains data from the network110 and displays it to the user within the application 533 interface.

Exemplary user devices are illustrated in some of the subsequent figuresprovided herein. This disclosure contemplates any suitable number ofuser devices, including computing systems taking any suitable physicalform. As example and not by way of limitation, computing systems may bean embedded computer system, a system-on-chip (SOC), a single-boardcomputer system (SBC) (such as, for example, a computer-on-module (COM)or system-on-module (SOM)), a desktop computer system, a laptop ornotebook computer system, an interactive kiosk, a mainframe, a mesh ofcomputer systems, a mobile telephone, a personal digital assistant(PDA), a server, or a combination of two or more of these. Whereappropriate, the computing system may include one or more computersystems; be unitary or distributed; span multiple locations; spanmultiple machines; or reside in a cloud, which may include one or morecloud components in one or more networks. Where appropriate, one or morecomputing systems may perform without substantial spatial or temporallimitation one or more steps of one or more methods described orillustrated herein. As an example, and not by way of limitation, one ormore computing systems may perform in real time or in batch mode one ormore steps of one or more methods described or illustrated herein. Oneor more computing system may perform at different times or at differentlocations one or more steps of one or more methods described orillustrated herein, where appropriate.

Network cloud 150 generally represents a network or collection ofnetworks (such as the Internet or a corporate intranet, or a combinationof both) over which the various components illustrated in FIG. 1(including other components that may be necessary to execute the systemdescribed herein, as would be readily understood to a person of ordinaryskill in the art). In particular embodiments, network 150 is anintranet, an extranet, a virtual private network (VPN), a local areanetwork (LAN), a wireless LAN (WLAN), a wide area network (WAN), ametropolitan area network (MAN), a portion of the Internet, or anothernetwork 150 or a combination of two or more such networks 150. One ormore links connect the systems and databases described herein to thenetwork 150. In particular embodiments, one or more links each includesone or more wired, wireless, or optical links. In particularembodiments, one or more links each includes an intranet, an extranet, aVPN, a LAN, a WLAN, a WAN, a MAN, a portion of the Internet, or anotherlink or a combination of two or more such links. The present disclosurecontemplates any suitable network 150, and any suitable link forconnecting the various systems and databases described herein.

The network 150 connects the various systems and computing devicesdescribed or referenced herein. In particular embodiments, network 150is an intranet, an extranet, a virtual private network (VPN), a localarea network (LAN), a wireless LAN (WLAN), a wide area network (WAN), ametropolitan area network (MAN), a portion of the Internet, or anothernetwork 421 or a combination of two or more such networks 150. Thepresent disclosure contemplates any suitable network 150.

One or more links couple one or more systems, engines or devices to thenetwork 150. In particular embodiments, one or more links each includesone or more wired, wireless, or optical links. In particularembodiments, one or more links each includes an intranet, an extranet, aVPN, a LAN, a WLAN, a WAN, a MAN, a portion of the Internet, or anotherlink or a combination of two or more such links. The present disclosurecontemplates any suitable links coupling one or more systems, engines ordevices to the network 150.

In particular embodiments, each system or engine may be a unitary serveror may be a distributed server spanning multiple computers or multipledatacenters. Systems, engines, or modules may be of various types, suchas, for example and without limitation, web server, news server, mailserver, message server, advertising server, file server, applicationserver, exchange server, database server, or proxy server. In particularembodiments, each system, engine or module may include hardware,software, or embedded logic components or a combination of two or moresuch components for carrying out the appropriate functionalitiesimplemented or supported by their respective servers. For example, a webserver is generally capable of hosting websites containing web pages orparticular elements of web pages. More specifically, a web server mayhost HTML files or other file types, or may dynamically create orconstitute files upon a request, and communicate them to clients devicesor other devices in response to HTTP or other requests from clientsdevices or other devices. A mail server is generally capable ofproviding electronic mail services to various clients devices or otherdevices. A database server is generally capable of providing aninterface for managing data stored in one or more data stores.

In particular embodiments, one or more data storages may becommunicatively linked to one or more servers via one or more links. Inparticular embodiments, data storages may be used to store various typesof information. In particular embodiments, the information stored indata storages may be organized according to specific data structures. Inparticular embodiment, each data storage may be a relational database.Particular embodiments may provide interfaces that enable servers orclients to manage, e.g., retrieve, modify, add, or delete, theinformation stored in data storage.

The system may also contain other subsystems and databases, which arenot illustrated in FIG. 1 , but would be readily apparent to a person ofordinary skill in the art. For example, the system may include databasesfor storing data, storing features, storing outcomes (training sets),and storing models. Other databases and systems may be added orsubtracted, as would be readily understood by a person of ordinary skillin the art, without departing from the scope of the invention.

FIG. 2 illustrates the various modules and sub-modules of monitoringsystem 120 (i.e., checkup system) in accordance with an embodiment ofthe invention. The monitoring system 120 includes a judicial processdata store 202, a data request module 122, a notification calendar 124,a mobile device notification interface 126, a user profile generator206, a location monitoring system 208 and a compliance monitoring system210. Other systems and databases may be used, as would be readilyunderstood by a person of ordinary skill in the art, without departingfrom the scope of the invention.

The monitoring system 120 receives the judicial data 160 and retains itin the judicial process data store 202. The judicial data 160 isnecessary to relate to each parolee to effectuate the monitoring system.

The monitoring system 120 includes a data request module 122 whichrequests data and information from the supervision officer. Themonitoring system 120 also includes a user profile generator 206, whichgenerates user profiles to send through the notification system 140 toparolees' mobile computing devices 170. The user profile is correlatedwith the individual parolee information provided by the supervisionofficer and is accessible to the supervision officer via the supervisionofficer's computing device 110.

The monitoring system 120 includes a mobile device notificationinterface 126 which allows the parolee's mobile computing device 170 andthe monitoring system 120 to communicate. The mobile device notificationinterface 126 can include access to a push notification system toprovide push notifications to the parolee's mobile computing device 170when required by the administrator or system. The timing of thecommunications between the parolee's mobile computing device 170 and themonitoring system 120 is determined by the notification calculator 124and effectuated through the notification system 140. The notificationcalculator 124, utilizes the judicial data 160 and other data providedby the supervision officer to calculate when to send notification to theparolee's mobile computing device 170.

In addition to generating notifications for parolees about individualcourt mandated appointments and required check-ins, the monitoringsystem 120 includes a location monitoring system 208 and a compliancemonitoring system 210. The location monitoring system 208 may monitorthe parolee's mobile computing device's 170 location in a specified areaor may monitor if a parolee's mobile computing device 170 is outside aspecified area. The monitoring system 120 may then send a notificationto the supervision officer's computing device 110 if there aredeviations from set parameters. The compliance monitoring system 210monitors the parolee's compliance and alerts the supervision officer'scomputing device 110 if the parolee is not in compliance. A variety ofdifferent monitoring methodologies may be used, as would be readilyunderstood to a person of ordinary skill in the art, without departingfrom the scope of the invention.

FIG. 3 illustrates a flowchart for monitoring a parolee in accordancewith an exemplary embodiment of the present invention. The processstarts by obtaining judicial data 302 for individual parolees. Thejudicial data may include name, address, birthday, court appearancedates, and drug testing dates.

After obtaining judicial data 302, the process generates a user profile304 which is sent to the parolee's mobile computing device 170. Theparolee then responds according to the parameters requested. The userprofile is stored and may be accessed by the supervision officer'scomputing device 110 as needed.

After the user profile is generated 304, the process will calculatenotifications 306 to be sent to the parolee's mobile computing device170 and the supervision officer's computing device 110. The notificationparameters may be established by the supervision officer or court or insome other way that is apparent and obvious to someone skilled in theart.

Once the notifications are calculated 306, the process will generatenotifications 308 on a predetermined basis and send notifications to theparolee's mobile computing device 170 and/or the supervision officer'scomputing device 110. The parolee will then respond to the notificationsthrough his/her mobile computing device 170 to ensure compliance. Ifnon-compliance is detected, the supervision officer's computing device110 will receive a predetermined notification.

The process may obtain image data 312 from the parolee's mobilecomputing device 170 which may be accessed by the supervision officer'scomputing device 110.

Finally, the process will continue to monitor compliance 314 with theparameters indicated by the supervision officer and will providenotifications as instructed. While the process is monitoring compliance314, notifications may be sent when a parolee fails to check in within apredetermined time frame, or if a parolee's mobile computing device isoutside a specified geographic area, or if a parolee fails to appear ata court hearing or at other court mandated location.

Exemplarily, the monitoring of the end user compliance of step 314 caninclude scoring of the end user's compliance or generating a score forthe end user's compliance. Exemplarily, the end user's activities,including location data and a comparison to geographic features definedfor the end user can be compiled. In some embodiments, the scoring caninclude scores for maintaining the proper geographic boundaries, notentering restricted areas, and accounting for times where the end useris recording being in violation of these and other boundaries. Inaddition, the scoring report can include scores based on the end user'spromptness in responding to notices, agenda events, and requiredcheck-in events. In additional embodiments, these scores and the timestamps at which certain events are recorded can be collated andgenerated into a timeline report as described below, for example, inFIG. 9 .

Further embodiments of the exemplary system described in FIGS. 1 and 2and the method of FIG. 3 may be directed towards flexible securityprofiles. These flexible security profiles may be adjusted to satisfythe requirements of an administrator monitoring end users. Exemplarily,the administrator can monitor the end users via the end user devices ofthe end user via communication with the end user through apps installedon the end user device. In some embodiments, the administrator may actas a parolee monitoring capacity. In a parolee monitoring capacity, theend users may subject to high security measures. Other additional highsecurity measure embodiments can include pretrial monitoring and in thecapacity of monitoring persons in custody released via bail bond by abail bondsman. In other exemplary uses, a low security measure scenariocan be employed. In low security measure scenarios, an employer may wishto monitor the location and actions of employees. For example, deliverydrivers, pool cleaners, and nurses on assignment or in a hospital can bemonitored.

In these scenarios, two exemplary types of tracking requests can be sentto an End User from an administrator. For example, in a high securitymeasure embodiment, the administrator can choose to engage an activeapproach where check-ins, agendas, and curfews are employed. Theseexemplary active measure can require the action of the end user pickingup a registered smart phone, taking a real time selfie, signing it, andsending the photo or other check-in information to the supervisor oradministrator. In examples of the passive tracking scenario, theapplication may be running be it in first exemplary plane where the appis opened or in a second exemplary plane, or in the background, wherethe app is running but not open. In some embodiments, the app will beprovided or stored on an end user's smart phone while in otherembodiments, other electrical devices with internet connectivity may beused, such as a smartpad or laptop.

In exemplary embodiments, a security profile for compliance monitoringof a parolee can be generated by the administrator. Exemplarily, thesecurity profile can identify one or more of basic features, geographicfeatures, and identification features to facilitate the monitoring ofthe end user through the end user device. In some embodiments, the basicfeatures can include one or more of a check-in event, an agenda event, acurfew event, and a timeline event The curfew event can include a datarequest for at least one of geo-location of the recipient mobile device,a time-block defining a curfew start time and a curfew end time, a timewindow for sending pings to the recipient mobile device within the timeblock. Exemplarily, the time window is a subset of the time period and afrequency of pings are sent to the recipient mobile device within thetime window. Exemplarily, the curfew event can start with the end userbeing notified of the curfew event. In additional embodiments, thetime-block for the curfew event can be initiated once the end userconducts an initial check-in for the curfew event. Once the check-in hasbeen completed then the time-block and the frequency of pings cancommence. In additional embodiments, the initiation of these time-blocksand the frequency of pings may commence at a random time within thecurfew event.

In additional exemplary embodiments, the geographic features forsecurity profile can include areas to which the end user must maintain aphysical presence. In some embodiments, the geographic features caninclude a geo-fence that defines the areas to which the end user isconfined. In other embodiments, the geographic features can includegeographic areas to which the end user is forbidden from entering. Insome embodiments, the geographic areas can include a curfew event area,such as a smaller area such as a domicile, a block, an apartmentcomplex, or other area to which the end user should stay during thecurfew event. In some embodiments, future curfew event locations havebeen defined by the location of the first curfew. In additionalembodiments, a small geofence is created within 100 feet of the check-inGPS location. If the end user were to leave that area the administratorswould be notified. Thus, eliminating people doing their curfew and thenleaving their homes. In additional embodiments, the geographic featurescan include wider areas to which the end user is confined duringnon-curfew events.

In additional exemplary embodiments, the identification features for thesecurity profile can include a check-in event. Exemplarily, the check-inevent can be an instance or process where the end user can identifyhimself through the end user device. In some examples of the check-inevent, the user may use an imaging device on the end user device to takea self-image, or have a third person take an image of the end user, toconfirm that the end user is present with the end user device. Inadditional embodiments of the check-in event, the end user can use thetouch-glass feature of the end user device to physically sign that he ispresent with the end user device. In yet other embodiments of thecheck-in event, the end user may be required to scan a QR code or otherimage to confirm that the end user is at a certain location with the enduser device. In additional embodiments, the check-in event can requirethe end user to engage in a chat, instant message, or video chatcommunication via the end user device through the equipment of theadministrator.

In another exemplary embodiment of the present invention, an agendaevent can include a set of directions for the end user. Exemplarily,these instructions for the agenda event are provided by theadministrator. In some embodiments, the agenda event can include readingmaterials to be read by the end user through the end user device. Inadditional embodiments, the agenda event can include instructions totravel to a certain location and check-in at that location. For example,the end user may be instructed to travel to a support group, a half-wayhouse, drug testing, job training, court appearance, or otherappropriate activities and events. At these events, the end user may berequired to check-in with a third party. The third party can thenprovide the user a code, a QR code, a signature, or other confirmationthat the end user has successfully arrived and participated in therequired activity. In other embodiments, the end user can self-certifyby performing a check-in as well as by providing images of hissurroundings or by scanning a QR code or another image. In someembodiments, the geo-fence or geographic features can be modified by theadministrator to allow the end user to travel to the defined locationwithout violating the geographic features.

FIG. 4 illustrates a flowchart illustrating exemplary method 400 foradding a new user to a security profile by an administrator of thesystem. The method 400 may exemplarily start at step 405 where theadministrator registers a new client, also referred to as the end user,the person for whom the app and smart phone, or other end user devices,will be registered. Exemplarily, in step 410, the end user downloads theapp onto the end user device. In some embodiments, the end user candownload the app from an online store, from the administrator's websiteor file storing site, or the end user can obtain a smartphone with theapp already preloaded. Then, in step 415, the end user can exemplarilyregister by providing a username and password. In other embodiments, theend user may be pre-assigned with these log-in credentials. Once the enduser has logged in in step 415, the administrator can, in step 420,receive the log-in information from the end user's device or smartphone.

Exemplarily, once the administrator receives the end user information,step 425 exemplarily includes the administrator instructing the app tovalidate the end user smart phone or other end user device. In step 425,the validation can include checking whether the smart phone or other enduser device being registered meets the minimal requirements. Minimalrequirements can include the presence of a location device, such as GPScapacity, as well as ensuring the device includes an image device, suchas a camera and the ability to record images. Other validation steps canexemplarily include checking the smart phone's phone number, an(International Mobile Equipment Identity) IMEI number, locationinformation, and other appropriate data. Exemplarily, the verificationcan determine if the smart phone or end user device will work properlyaccording to the end user profile.

In step 430, a determination is made as to whether the end user devicemeets these requirements. Exemplarily, this step can be performed on theserver or via a web-based decision-making website. If the end userdevice fails the requirements check, then in step 435, the administratoris informed, and the administrator can inform the end user of thisissue. Upon a successful validation of the end user device, then in step440, the app on the end user device can receive a first-timeconfiguration. The first-time configuration can exemplarily includeproviding the device with check-in times, a timeline, an agenda,geo-point information, and geofence information.

Upon the completion of step 440, the app can perform step 445 where theend user performs a first-time check-in via the app on the end userdevice. In some embodiments, the first-time check-in can include a firstphoto of the end user via the end user device. Other information canalso be collected and relayed to the administrator at this point, suchas the phone IMEI, phone number, and location information. Theadministrator receives this information and in step 450 approves thefirst check in. Exemplary, the photo may be verified to determine if itmatches the end user. In step 455, the first-time check-in can bechecked to ensure the information is for a new profile or includesproper information. Upon the completion of step 455, method 400 canreturn to step 445 to retry the first-time check-in or the registrationis completed in step 460.

FIG. 5 illustrates an exemplary user-interface 500 that may be presentedto a computing device associated with an administrator. Exemplarily, theadministrator can select various options presented in the user interfaceillustrated in FIG. 5 to generate a security profile for a parolee. Theadministrator's selection of the various options may be based on, forexample, judicial order or other requirements that the parolee mustcomply with, and/or administrative requirements associated with thelocal parole administration system. In one embodiment, the variousoptional elements illustrated in FIG. 5 may be preset based on specificrequirements and/or preferences associated with each paroleadministration agency and/or based on judicial order documents that areuploaded into the server and/or obtained from court records data.

As illustrated in FIG. 5 , the elements of a security profile maycomprise basic features 510, geographic features 520, and identificationfeatures 530.

Exemplary basic features 510 may comprise check-in events 512, agendaevents 514, curfew events 516, and time-line events 518. Each of thebasic feature 510 events may comprise additional rules and/orsub-requirements which may be optionally selected by a paroleadministrator. More specifically, each basic feature 510 event maycomprise rules regarding timing of pings that may be sent to theparolee's mobile device, frequency of pings that may be sent to theparolee's mobile device, and/or duration of pings that may be sent tothe parolee's mobile device. In addition, each event may comprise rulesregarding data that must be obtained from the parolee, wherein thedocuments may help establish whether the parolee is in compliance withconditions of his or her parole. Requests for additional data and/ordocuments may include, for example, a signature of the parolee to verifythe veracity of the parolee's response to a ping, notes, readingmaterial that the parolee may be required to read, responses or notesassociated with the reading material that the parolee may have writtendown, etc. In some embodiments, the event may require data fromthird-parties other than a parolee, a parole officer, or the paroleadministration, including, but not limited to a half-way houseadministrator, a support group administrator, a drug test administrator,etc. In these instances, the third-party may scan data that is presentedto the parolee's mobile device, such as, but not limited to a QR code.The scanned data may be transmitted from the third-party's computingdevice to the check-up system 120. In other embodiments, the parolee maybe required to scan a code or an identifier that is located at aspecific geo-location via the parolee's mobile device. The can data maybe sent to the check-up system 120. In other examples, geo-location dataassociated with the user device at the time of the ping (and/or at thetime that a response to the ping is generated) may be required as partof an optional sub-requirement associated with a basic feature 510event.

Each basic feature 510 event (for example, check-in events 512, agendaevents 514, curfew events 516, and time-line events 518) may have aspecific rules regarding pings that are sent to a parolee's mobiledevice. The rules may specify the timing of pings, frequency of pings,and/or duration of pings that may be sent to the parolee's mobiledevice. Additionally, each basic feature 510 event may specifytolerances for when responsive data in response to a ping must bereceived from the parolee's mobile device before the parolee's responseis deemed non-compliant.

For example, a check-in event 512 may specify a specific time forsending pings to the mobile device of the parolee. The time may be thesame for each day of the week, may vary according to a pre-set scheduleor may be randomized. As mentioned above, a check-in event 512 mayadditionally and/or optionally require certain data from the parolee'smobile device including but not limited to a picture of the parolee thatis taken contemporaneously (i.e. not retrieved from the mobile device'slong term storage and/or having a time-stamp or metadata identifyingthat the picture was taken within 30 seconds or some other threshold ofsubmitting responsive data in response to the ping). Additionally, thecheck-in event 512 may require the parolee's mobile device to submit ageo-location associated with the mobile device's current location. Thegeo-location information may comprise, for example, GPS location.Additionally, the check-in event 512 may require the parolee's device tosubmit cell tower information associated with the uplink/downlink ofdata and/or cellular service on the parolee's mobile device 170.Additionally and/or optionally as selected in the parolee's securityprofile, signature may be required to be provided by the parolee when acheck-in ping is received and/or when a response to the ping isgenerated and/or sent to the servers. Additionally, or optionally, thecheck-in event 512 may specify a tolerance within which time aresponsive submission must be received from the parolee's mobile device.For example, a check-in event 512 may specify that a response must bereceived from the parolee's mobile device within 30 minutes of sending aping. The specific times frames may vary, as would be understood bypersons of ordinary skill in the art, without departing from the scopeof the invention. If a response is not received within a particular timeframe, then the parolee's response may be deemed non-compliant. In oneembodiment, a score may be assessed based on the timeliness of theparolee's response as described in reference to FIG. 3 .

The agenda event 514 specifies a variety of requirements for pinging themobile device 170 of a parolee as well as responsive data that may berequested from the parolee's mobile device 170. In one embodiment, theagenda event 514 may specify a time for sending pings to the mobiledevice 170 of the parolee. The time may be the same for each day of theweek, may vary according to a pre-set schedule or may be randomized.Additionally, the agenda event 514 may specify a duration of the agenda,including but not limited to, a start time and an end time, and/orfrequency of pings to send to the parolee's mobile device during theagenda event. Additionally and/or optionally, the agenda event 514 mayrequire submission of certain data from the parolee's mobile device 170and/or the computing device of a third party. The additional/optionalrequired data may include geo-location data associated with theparolee's current location, including but not limited to GPS coordinatedata, image files from the parolee's mobile device wherein the imagefile is taken contemporaneously of being sent to the checkups system 120(or within a threshold period of time), and the like. In one embodiment,the agenda event 514 may require third party data and/or data from athird party device.

The curfew event 516 may also specify a variety of requirements forpinging the mobile device 170 of the parolee as well as responsive datathat may be requested from the parolee's mobile device 170. In oneembodiment, the requirements associated with the curfew event 516 maycomprise data request for at least one of geo-location of the recipientmobile device, a time-block defining a curfew start time and a curfewend time, a time window for sending pings to the recipient mobile devicewithin the time block, wherein the time window is a subset of the timeperiod, and a frequency of pings to send to the recipient mobile devicewithin the time window.

The timeline event 518 can include tracking the end user device atpredetermined time intervals. In addition, the timeline can provide theadministrator with a visual reference of these tracking events and otherevents monitored by the end user device. Other exemplary end userprofile creation tools can include geofences that can include locationsthat the end user device, and therefore the end user, cannot leave orcannot enter. The end user profile creation tool can further specify amedia access control (MAC) address reporting by the end user device, aclient number reporting requirement, and a device ID requirement wherethe end user device reports its IMEI or Vendor ID where appropriate.

Exemplarily, the administrator can be provided with tracking informationthat is received from the end user device. Exemplary trackinginformation can include precise smart phone verification. Examples ofsmart phone verification can include checking the cell phone number forthe end user device, a MAC address for the end user device, an IMEInumber, or a vendor ID for the device. Additional tracking informationcan include vicinity verification through cell tower polygonconfirmation, cell phone tower triangulation, and GPS reports from theend user device.

Additionally, geographic boundaries can be defined by the administratorthrough the system. Exemplary control of the geographic boundaries caninclude control of geofence requirements. Exemplarily, the geofence canbe specified for an end user rather than simply requiring the end userto remain within a geofence defined by a metropolitan or other largearea. Additional exemplary geographic boundaries can includegeorestricted locations that the end user is not allowed to enter. Inadditional embodiments, the end user, as tracked by the end user device,which must remain with the end user as part of his or her participationin a high security measure system can include defining a curfew for theend user.

Additional protective security measures can include identifying misuseof the app or the end user device by viewing root permissions.Exemplarily, viewing root permissions will be enabled for the end userdevice for the app to monitor. Another exemplary protective securitymeasure can include instant location being request from the end userdevice by the app, and sent by the administrator, via a pushnotification where the administrator can receive and view the locationof any user device registered with the administrator.

In additional embodiments, various end user confirmation events can beinstituted. Exemplary instances of end user confirmation events caninclude a QR agenda confirmation event. A QR agenda confirmation eventcan include the end user being required to scan a QR code at a certaintime or place. Another end user confirmation event can include requiringa written or digital signature to be provided by the end user.Exemplarily, the end user must provide a signature, for example beinghand drawn on the surface of the smart phone where the signature isrecorded and provided to the administrator. In another end userconfirmation event, the end user is required to take self-images asdirected by the administrator through the app. Exemplarily, these imageswill be taken by the smart phone's camera and transmitted, via the app,to the administrator. In additional embodiments, the images can bemoving images such as gifs or videos. In addition, the end user may alsobe required to sign the image as described above.

Exemplarily, the apps on the end user devices have API REST enabled toensure servers for a web suite providing administrative services areavailable. This can allow for administrator side actions even when theapps are not actively communicating with the web suite or servers of theadministrators to minimize drainage of the end user device battery oroverusing the subscriptions or data plans for the end user device.Exemplarily, the channels the servers and the app use to communicate canbe encrypted to maintain a private internet connection and to preventany outside modification of messaging between the end user andadministrators.

Exemplarily, the channel utilized for transferring information betweenthe end user device and the servers is not always on to minimize batteryusage for the end user device. Instead the end user devices can beconfigured to store the various information (e.g., a timeline, agenda,check-in, etc.) collected by the end user devices until they have beenawoken by the end user and can transfer data. This process can depend onthe latency of the devices but in average a smart phone user wakes uphis/her smart phone 52 times per day. Exemplarily, the app can workwithout being connected or talking with the server and information thatwas collected may be transmitted once there is a reestablish of aconnection with the system, cell towers, or internet. By minimizingserver interactions, the amount of data being by the end user device canbe minimized, allowing the end user device to not require long batterylife or expensive data plans.

FIG. 6 illustrates exemplary method 600 in which a curfew, such as thecurfew event selected in FIG. 5 , for an end user is performed.Exemplarily, in step 610, the curfew requirements are entered into thesystem by the administrator, as exemplarily illustrated above in step440 and in FIG. 5 . Exemplarily, in step 620, the app notifies the enduser of either the beginning or the end of a first curfew. Exemplarily,the first curfew will inform the app and the administrator of details ofthe end user's curfew area to determine future curfews. In someembodiments, this curfew area can be an area of about 100 feetsurrounding the point at which the end user performed the first curfewcheck-in. In other embodiments, this curfew area can be limited to adomicile, building, or apartment complex at that location. For example,in step 620, the end user will register the first curfew with the app inthe end user device. Registering the first curfew can be performed byinteracting with the app as directed by instructions provided from theapp to be performed by the end user. First curfew information caninclude location information for the end user device during the firstcurfew time period. This can exemplarily set a geoboundary, orgeographic feature, for the end user as it should conform with the enduser's domicile or residence. In step 630, the app directs the end userdevice to transmit this first curfew information to the administrator.In step 640, the administrator can review the first curfew informationand either approve that information. Approved first curfew informationis then added to the end user profile for future curfews in step 650. Ininstances where the administrator denies the first curfew information,step 660 will reset to step 620 to reattempt to the first curfewprocess.

Exemplarily, the timing of pinging events within a curfew can berandomized so as to happen between any one hour to prevent the end userfrom predicting the timing of the curfew. Exemplarily, the curfew islinked to a location, the location exemplarily, being determined by aGPS position or a cell tower location mechanism. Exemplarily, ininitiating the curfew from the end user device, the end user provides acheck-in. The curfew event check-in can include performing theself-image process where the end user uses the imaging device on the enduser device to confirm he is present with the end user device. Duringthe curfew, the end user device can be pinged by the administratorservers or web suite several times an hour to ensure the end user deviceis not being moved from that location. Typically, the curfew will lastabout two hours and if the curfew is not complied with by the end user,a notification can be provided to the administrator. In addition, theend user device can continue to monitor device for a period of timeafter the curfew ends. Check-ins during the curfew can take place via aninteraction with the app on the end user device, including signaturesand image taking.

Exemplarily, the administrator can receive constant notification of enduser events. In some embodiments, these events can be provided to theadministrator via a web suite. Via this web suite, the administrator canexemplarily control the rules and events for an end user. Changes tothese rules will set forth a chain reaction of notifications within thesystem to let all other administrator know of these changes, whereappropriate depending on permissions as required within an organization.For example, there may be several tiers of administrator within anorganization, and some administrators may have different authorizationlevels.

FIG. 7 illustrated an exemplary method 700 for modifying an end useraccount. Exemplarily, in step 710, an administrator accesses the systemto modify the end user profile. These modifications can include changesto check-in times, a timeline, the end user's geographic features and/orgeofence, and agendas to be provided to the end user via the appoperating on the end user device. Exemplarily, in step 710, webserverscan update the servers for the system and in step 720 the webservers canupdate information queues and push notifications for the end userprofile. Then, in step 730, the app on the end user device can receivethese push notifications. Upon receiving these push notifications, theapp can force synchronization of information contained in thesenotifications with the various functionalities of the app which takesplace in step 740. Method 700 can then be completed in step 750 wherethese changes are saved within the app in the end user device.

Another end user confirmation event can be the creation of anddistribution of forms, as previously discussed with respect to theagenda events. Exemplarily, the end user would be required to be at acertain location at a predetermined time. In addition, in an agendaevent, the forms can be created by the administrator via the system. Theend user can then fill out the form, answer any questions containedwithin the form, and provide feedback through the form. The completedform can then be broadcast from the device back to the administrator.Additional embodiments of the agenda can include a requirement that theend user be present at a certain location. In additional embodiments,the agenda can require the end user to interact with a person, computer,or interface at the certain location. For example, in some instances,the end user may be required to perform a check-in at the certainlocation. In other instances, the end user may be required to scan a QRcode or take other images at the certain location.

FIG. 8 illustrates an exemplary interface for the administrator tomonitor the performance of an agenda event by the end user. Exemplarily,the administrator can use this interface to define when and where theend user will perform a check-in according to this agenda event. In someembodiments, the administrator can choose dates from a calendar functionfor the end user. After selecting a time and date for the agenda to takeplace, the administrator can then use the interface of FIG. 8 to selectthe various activities to take place during the agenda event. Inaddition, the administrator can provide notes to the end user throughthis interface. In addition, the administrator can select whether athird person or party will take part in this agenda event.

In additional embodiments, the administrator can include additionalinformation for the end user to read or acts to perform. These acts caninclude scanning a QR code at the location, taking an image at thelocation, or signing a signature through the app on the end user device.In addition, the administrator can provide an email to a third party inthe event the end user is to meet with that third party as part of theagenda. In some instances, the third party may be provided with the QRcode so that the end user will have to interact with the third party toobtain the QR code. In exemplary instances of this agenda, the end user,such as a parolee may have to meet with a third party to receivetraining, perform a test, or to fulfill conditions of the parole.

At a predetermined time before the agenda begins, the end user willreceive a notification of the agenda event. Exemplarily, a score can beassessed for the agenda based on how close the end user comes to thecheck-in point and how prompt the end user is at performing thecheck-in. In addition, FIG. 9 illustrates a timeline report according toembodiments of the present invention. In some embodiments, the timelinecan be provided to the administrator to detail activities of the enduser, alerts generated by the end user device, and other information asthey occurred according to when those alerts or events occurred.

Exemplarily, the administrator can select the timeline feature which canping the end user every 15 minutes, or at another determined frequency.Exemplarily, the timeline will compare the end user device location tothe geographic feature requirements for the end user as set by theadministrator and give it a score. For example, if the end user deviceis pinged and found to be inside the geofence, this can be given ascore, as discussed above with respect to step 314 of FIG. 3 , and ifthe end user is found to be close to the geofence then less points canbe awarded. In events where the ping shows the end user is outside thegeofence, the end user loses more points. In additional embodiments,other factors can be considered. For example, the score can reflect ifthe timeline was sent on time or it was stored by the phone and sentlater, or if the timeline was sent at all. Once the information isreceived and analyzed, the result is placed in the timeline of theindividual so the administrator can view the historic data at any time.If one of these timelines is not inside the geofence, the administratorwill receive an email notifying them of this. In additional embodiments,a heatmap can be created if a supervisor wants to compare all of thesetimeline points in a visual manner.

Hardware Architecture

Generally, the techniques disclosed herein may be implemented onhardware or a combination of software and hardware. For example, theymay be implemented in an operating system kernel, in a separate userprocess, in a library package bound into network applications, on aspecially constructed machine, on an application-specific integratedcircuit (ASIC), or on a network interface card.

Software/hardware hybrid implementations of at least some of theembodiments disclosed herein may be implemented on a programmablenetwork-resident machine (which should be understood to includeintermittently connected network-aware machines) selectively activatedor reconfigured by a computer program stored in memory. Such networkdevices may have multiple network interfaces that may be configured ordesigned to utilize different types of network communication protocols.A general architecture for some of these machines may be describedherein in order to illustrate one or more exemplary means by which agiven unit of functionality may be implemented. According to specificembodiments, at least some of the features or functionalities of thevarious embodiments disclosed herein may be implemented on one or moregeneral-purpose computers associated with one or more networks, such asfor example an end-user computer system, a client computer, a networkserver or other server system, a mobile computing device (e.g., tabletcomputing device, mobile phone, smartphone, laptop, or other appropriatecomputing device), a consumer electronic device, a music player, or anyother suitable electronic device, router, switch, or other suitabledevice, or any combination thereof. In at least some embodiments, atleast some of the features or functionalities of the various embodimentsdisclosed herein may be implemented in one or more virtualized computingenvironments (e.g., network computing clouds, virtual machines hosted onone or more physical computing machines, or other appropriate virtualenvironments).

Referring now to FIG. 10 , there is shown a block diagram depicting anexemplary computing device 10 suitable for implementing at least aportion of the features or functionalities disclosed herein. Computingdevice 10 may be, for example, any one of the computing machines listedin the previous paragraph, or indeed any other electronic device capableof executing software- or hardware-based instructions according to oneor more programs stored in memory. Computing device 10 may be configuredto communicate with a plurality of other computing devices, such asclients or servers, over communications networks such as a wide areanetwork a metropolitan area network, a local area network, a wirelessnetwork, the Internet, or any other network, using known protocols forsuch communication, whether wireless or wired.

In one aspect, computing device 10 includes one or more centralprocessing units (CPU) 12, one or more interfaces 15, and one or morebusses 14 (such as a peripheral component interconnect (PCI) bus). Whenacting under the control of appropriate software or firmware, CPU 12 maybe responsible for implementing specific functions associated with thefunctions of a specifically configured computing device or machine. Forexample, in at least one aspect, a computing device 10 may be configuredor designed to function as a server system utilizing CPU 12, localmemory 11 and/or remote memory 16, and interface(s) 15. In at least oneaspect, CPU 12 may be caused to perform one or more of the differenttypes of functions and/or operations under the control of softwaremodules or components, which for example, may include an operatingsystem and any appropriate applications software, drivers, and the like.

CPU 12 may include one or more processors 13 such as, for example, aprocessor from one of the Intel, ARM, Qualcomm, and AMD families ofmicroprocessors. In some embodiments, processors 13 may includespecially designed hardware such as application-specific integratedcircuits (ASICs), electrically erasable programmable read-only memories(EEPROMs), field-programmable gate arrays (FPGAs), and so forth, forcontrolling operations of computing device 10. In a particular aspect, alocal memory 11 (such as non-volatile random-access memory (RAM) and/orread-only memory (ROM), including for example one or more levels ofcached memory) may also form part of CPU 12. However, there are manydifferent ways in which memory may be coupled to system 10. Memory 11may be used for a variety of purposes such as, for example, cachingand/or storing data, programming instructions, and the like. It shouldbe further appreciated that CPU 12 may be one of a variety ofsystem-on-a-chip (SOC) type hardware that may include additionalhardware such as memory or graphics processing chips, such as a QUALCOMMSNAPDRAGON™ or SAMSUNG EXYNOS™ CPU as are becoming increasingly commonin the art, such as for use in mobile devices or integrated devices.

As used herein, the term “processor” is not limited merely to thoseintegrated circuits referred to in the art as a processor, a mobileprocessor, or a microprocessor, but broadly refers to a microcontroller,a microcomputer, a programmable logic controller, anapplication-specific integrated circuit, and any other programmablecircuit.

In one aspect, interfaces 15 are provided as network interface cards(NICs). Generally, NICs control the sending and receiving of datapackets over a computer network; other types of interfaces 15 may forexample support other peripherals used with computing device 10. Amongthe interfaces that may be provided are Ethernet interfaces, frame relayinterfaces, cable interfaces, DSL interfaces, token ring interfaces,graphics interfaces, and the like. In addition, various types ofinterfaces may be provided such as, for example, universal serial bus(USB), Serial, Ethernet, FIREWIRE™, THUNDERBOLT™, PCI, parallel, radiofrequency (RF), BLUETOOTH™, near-field communications (e.g., usingnear-field magnetics), 802.11 (WiFi), frame relay, TCP/IP, ISDN, fastEthernet interfaces, Gigabit Ethernet interfaces, Serial ATA (SATA) orexternal SATA (ESATA) interfaces, high-definition multimedia interface(HDMI), digital visual interface (DVI), analog or digital audiointerfaces, asynchronous transfer mode (ATM) interfaces, high-speedserial interface (HSSI) interfaces, Point of Sale (POS) interfaces,fiber data distributed interfaces (FDDIs), and the like. Generally, suchinterfaces 15 may include physical ports appropriate for communicationwith appropriate media. In some cases, they may also include anindependent processor (such as a dedicated audio or video processor, asis common in the art for high-fidelity A/V hardware interfaces) and, insome instances, volatile and/or non-volatile memory (e.g., RAM).

Although the system shown in FIG. 10 illustrates one specificarchitecture for a computing device 10 for implementing one or more ofthe embodiments described herein, it is by no means the only devicearchitecture on which at least a portion of the features and techniquesdescribed herein may be implemented. For example, architectures havingone or any number of processors 13 may be used, and such processors 13may be present in a single device or distributed among any number ofdevices. In one aspect, single processor 13 handles communications aswell as routing computations, while in other embodiments a separatededicated communications processor may be provided. In variousembodiments, different types of features or functionalities may beimplemented in a system according to the aspect that includes a clientdevice (such as a tablet device or smartphone running client software)and server systems (such as a server system described in more detailbelow).

Regardless of network device configuration, the system of an aspect mayemploy one or more memories or memory modules (such as, for example,remote memory block 16 and local memory 11) configured to store data,program instructions for the general-purpose network operations, orother information relating to the functionality of the embodimentsdescribed herein (or any combinations of the above). Programinstructions may control execution of or comprise an operating systemand/or one or more applications, for example. Memory 16 or memories 11,16 may also be configured to store data structures, configuration data,encryption data, historical system operations information, or any otherspecific or generic non-program information described herein.

Because such information and program instructions may be employed toimplement one or more systems or methods described herein, at least somenetwork device embodiments may include nontransitory machine-readablestorage media, which, for example, may be configured or designed tostore program instructions, state information, and the like forperforming various operations described herein. Examples of suchnontransitory machine-readable storage media include, but are notlimited to, magnetic media such as hard disks, floppy disks, andmagnetic tape; optical media such as CD-ROM disks; magneto-optical mediasuch as optical disks, and hardware devices that are speciallyconfigured to store and perform program instructions, such as read-onlymemory devices (ROM), flash memory (as is common in mobile devices andintegrated systems), solid state drives (SSD) and “hybrid SSD” storagedrives that may combine physical components of solid state and hard diskdrives in a single hardware device (as are becoming increasingly commonin the art with regard to personal computers), memristor memory, randomaccess memory (RAM), and the like. It should be appreciated that suchstorage means may be integral and non-removable (such as RAM hardwaremodules that may be soldered onto a motherboard or otherwise integratedinto an electronic device), or they may be removable such as swappableflash memory modules (such as “thumb drives” or other removable mediadesigned for rapidly exchanging physical storage devices),“hot-swappable” hard disk drives or solid state drives, removableoptical storage discs, or other such removable media, and that suchintegral and removable storage media may be utilized interchangeably.Examples of program instructions include both object code, such as maybe produced by a compiler, machine code, such as may be produced by anassembler or a linker, byte code, such as may be generated by forexample a JAVA™ compiler and may be executed using a Java virtualmachine or equivalent, or files containing higher level code that may beexecuted by the computer using an interpreter (for example, scriptswritten in Python, Perl, Ruby, Groovy, or any other scripting language).

In some embodiments, systems may be implemented on a standalonecomputing system. Referring now to FIG. 11 , there is shown a blockdiagram depicting a typical exemplary architecture of one or moreembodiments or components thereof on a standalone computing system.Computing device 20 includes processors 21 that may run software thatcarry out one or more functions or applications of embodiments, such asfor example a client application 24. Processors 21 may carry outcomputing instructions under control of an operating system 22 such as,for example, a version of MICROSOFT WINDOWS™ operating system, APPLEmacOS™ or iOS™ operating systems, some variety of the Linux operatingsystem, ANDROID™ operating system, or the like. In many cases, one ormore shared services 23 may be operable in system 20, and may be usefulfor providing common services to client applications 24. Services 23 mayfor example be WINDOWS™ services, user-space common services in a Linuxenvironment, or any other type of common service architecture used withoperating system 21. Input devices 28 may be of any type suitable forreceiving user input, including for example a keyboard, touchscreen,microphone (for example, for voice input), mouse, touchpad, trackball,or any combination thereof. Output devices 27 may be of any typesuitable for providing output to one or more users, whether remote orlocal to system 20, and may include for example one or more screens forvisual output, speakers, printers, or any combination thereof. Memory 25may be random-access memory having any structure and architecture knownin the art, for use by processors 21, for example to run software.Storage devices 26 may be any magnetic, optical, mechanical, memristor,or electrical storage device for storage of data in digital form (suchas those described above, referring to FIG. 11 ). Examples of storagedevices 26 include flash memory, magnetic hard drive, CD-ROM, and/or thelike.

In some embodiments, systems may be implemented on a distributedcomputing network, such as one having any number of clients and/orservers. Referring now to FIG. 12 , there is shown a block diagramdepicting an exemplary architecture 30 for implementing at least aportion of a system according to one aspect on a distributed computingnetwork. According to the aspect, any number of clients 33 may beprovided. Each client 33 may run software for implementing client-sideportions of a system; clients may comprise a system 20 such as thatillustrated in FIG. 12 . In addition, any number of servers 32 may beprovided for handling requests received from one or more clients 33.Clients 33 and servers 32 may communicate with one another via one ormore electronic networks 31, which may be in various embodiments any ofthe Internet, a wide area network, a mobile telephony network (such asCDMA or GSM cellular networks), a wireless network (such as WiFi, WiMAX,LTE, and so forth), or a local area network (or indeed any networktopology known in the art; the aspect does not prefer any one networktopology over any other). Networks 31 may be implemented using any knownnetwork protocols, including for example wired and/or wirelessprotocols.

In addition, in some embodiments, servers 32 may call external services37 when needed to obtain additional information, or to refer toadditional data concerning a particular call. Communications withexternal services 37 may take place, for example, via one or morenetworks 31. In various embodiments, external services 37 may compriseweb-enabled services or functionality related to or installed on thehardware device itself. For example, in one aspect where clientapplications 24 are implemented on a smartphone or other electronicdevice, client applications 24 may obtain information stored in a serversystem 32 in the cloud or on an external service 37 deployed on one ormore of a particular enterprise's or user's premises.

In some embodiments, clients 33 or servers 32 (or both) may make use ofone or more specialized services or appliances that may be deployedlocally or remotely across one or more networks 31. For example, one ormore databases 34 may be used or referred to by one or more embodiments.It should be understood by one having ordinary skill in the art thatdatabases 34 may be arranged in a wide variety of architectures andusing a wide variety of data access and manipulation means. For example,in various embodiments one or more databases 34 may comprise arelational database system using a structured query language (SQL),while others may comprise an alternative data storage technology such asthose referred to in the art as “NoSQL” (for example, HADOOP CASSANDRA™,GOOGLE BIGTABLE™, and so forth). In some embodiments, variant databasearchitectures such as column-oriented databases, in-memory databases,clustered databases, distributed databases, or even flat file datarepositories may be used according to the aspect. It will be appreciatedby one having ordinary skill in the art that any combination of known orfuture database technologies may be used as appropriate, unless aspecific database technology or a specific arrangement of components isspecified for a particular aspect described herein. Moreover, it shouldbe appreciated that the term “database” as used herein may refer to aphysical database machine, a cluster of machines acting as a singledatabase system, or a logical database within an overall databasemanagement system. Unless a specific meaning is specified for a givenuse of the term “database”, it should be construed to mean any of thesesenses of the word, all of which are understood as a plain meaning ofthe term “database” by those having ordinary skill in the art.

Similarly, some embodiments may make use of one or more security systems36 and configuration systems 35. Security and configuration managementare common information technology (IT) and web functions, and someamount of each are generally associated with any IT or web systems. Itshould be understood by one having ordinary skill in the art that anyconfiguration or security subsystems known in the art now or in thefuture may be used in conjunction with embodiments without limitation,unless a specific security 36 or configuration system 35 or approach isspecifically required by the description of any specific aspect.

FIG. 13 shows an exemplary overview of a computer system 40 as may beused in any of the various locations throughout the system. It isexemplary of any computer that may execute code to process data. Variousmodifications and changes may be made to computer system 40 withoutdeparting from the broader scope of the system and method disclosedherein. Central processor unit (CPU) 41 is connected to bus 42, to whichbus is also connected memory 43, nonvolatile memory 44, display 47,input/output (I/O) unit 48, and network interface card (NIC) 53. I/Ounit 48 may, typically, be connected to keyboard 49, pointing device 50,hard disk 52, and real-time clock 51. NIC 53 connects to network 54,which may be the Internet or a local network, which local network may ormay not have connections to the Internet. Also shown as part of system40 is power supply unit 45 connected, in this example, to a mainalternating current (AC) supply 46. Not shown are batteries that couldbe present, and many other devices and modifications that are well knownbut are not applicable to the specific novel functions of the currentsystem and method disclosed herein. It should be appreciated that someor all components illustrated may be combined, such as in variousintegrated applications, for example Qualcomm or Samsungsystem-on-a-chip (SOC) devices, or whenever it may be appropriate tocombine multiple capabilities or functions into a single hardware device(for instance, in mobile devices such as smartphones, video gameconsoles, in-vehicle computer systems such as navigation or multimediasystems in automobiles, or other integrated hardware devices).

In various embodiments, functionality for implementing systems ormethods of various embodiments may be distributed among any number ofclient and/or server components. For example, various software modulesmay be implemented for performing various functions in connection withthe system of any particular aspect, and such modules may be variouslyimplemented to run on server and/or client components.

The skilled person will be aware of a range of possible modifications ofthe various embodiments described above. Accordingly, the presentinvention is defined by the claims and their equivalents.

Graphical User Interfaces

FIG. 14 illustrates a system for monitoring parolees in accordance withan exemplary embodiment of the invention. The system may comprise aparolee database 1410, an officer account database 1415, a basicfeatures database 1420, a geographic features database 1422, anidentification features database 1424, a user interface engine 1430, auser input engine 1440, a compliance engine 1442, and a network 1450.Various databases may reside together within a bigger data storagestructure. For example, the parolee database 1410 and the officeraccount database 1415 may each comprise one or more tables within aprofile database. As another example, the basic features database 1420,the geographic features database 1422, and the identification featuresdatabase 1424 may each comprise one or more tables within a featuresdatabase. Various components may reside together within a single device.For example, the user interface engine 1430 and the user input engine1440 may reside together within a single user device or server. Thenetwork 1450 may facilitate communication between the various componentsof the system. The network 1450 may be or be similar to the network 150in FIG. 1 .

The parolee database 1410 may comprise parolee information. Paroleeinformation may comprise information a parole officer may use to developa monitoring and/or reporting system for the parolee, such as a releasedate, release conditions, offenses, punishments, notes from judges,prison guards, parole boards, etc. Parolee information may compriseparolee profile information, such as a name, an address, contactinformation, one or more pictures of the parolee, previous check-inevents, future scheduled check-in events, etc.

The officer account database 1415 may comprise officer accountinformation. Officer account information may comprise information anofficer may need to monitor parolees, such as parolees, previous paroleecheck-in events, future scheduled parolee check-in events, etc.

The basic features database 1420 may store basic feature preferences fora particular parolee. Basic feature preferences may influence howevents, such as check-in events, agenda events, curfew events, time-lineevents, etc., are captured for the particular parolee. An officer mayenter basic feature preferences in a GUI similar to what is shown inFIG. 5 and information about events captured for the parolee may be inaccordance with the entered basic feature preferences.

The geographic features database 1422 may store geographic featurepreferences for a particular parolee. Geographic feature preferences mayindicate an area a parolee is allowed to visit. Geographic featurepreferences may indicate an area a parolee is forbidden from visiting.An officer may enter geographic feature preferences in a GUI similar towhat is shown in FIG. 5 and geographic mandates and/or restrictionsassociated with the parolee may be in accordance with the enteredgeographic feature preferences.

The identification features database 1424 may store identificationfeature preferences for a particular parolee. Identification featurepreferences may indicate how a parolee will verify their identity. Anofficer may enter identification feature preferences in a GUI similar towhat is shown in FIG. 5 and identification information associated withthe parolee may be in accordance with the entered identification featurepreferences. Identification feature preferences may cause a deviceassociated with the parolee to automatically provide identificationinformation, which is stored in the identification features database1424. Identification feature preferences may indicate a preference forthe parolee to manually enter identification information, which isstored in the identification features database 1424.

The user interface engine 1430 will be described in more detail inreference to FIG. 15 . A user device associated with an officer maycomprise the user interface engine 1430. A server may comprise the userinterface engine 1430.

The user input engine 1440 may process input received from a GUI shownin FIG. 18 or FIG. 19A. For example, the user input engine 1440 maycause parolee check-in entries associated with a particular officer tobe displayed. The particular officer may enter a date range, and theuser input engine 1440 may cause parolee check-in entries associatedwith a particular officer within the entered date range to be displayed.The particular officer may select a check-in entry, and the user inputengine 1440 may cause information associated with the selected check-inentry to be populated on the GUI. The particular officer may engage anaccept element associated with the selected check-in entry, and the userinput engine 1440 may cause the selected check-in entry to be accepted.The particular officer may engage a deny element associated with theselected check-in entry, and the user input engine 1440 may cause theselected check-in entry to be denied. The particular officer may enterinformation into a field associated with a reason for denial of theselected check-in entry, and the user input engine 1440 may cause theentered information to be stored with the selected check-in entry.

The compliance engine 1442 may compute a compliance score for eachcheck-in entry. The compliance engine 1442 may assign a score based on acomparison of actual information with expected information. For example,if an entry has an expected time of 7:00 PM, then the closer the actualcheck-in time is to 7:00 PM, the higher the score may be. The actualinformation may comprise an actual check-in time, and the expectedinformation may comprise an expected check-in time. The actualinformation may comprise an actual check-in location, and the expectedinformation may comprise an expected check-in location. The actualinformation may comprise actual verification information, and theexpected information may comprise an expected verification information.The verification information may comprise at least one of a signature, apicture of the parolee taken contemporaneously, a picture of a locationtaken contemporaneously, etc. Engagement of an accept element may causethe compliance engine 1442 to increase an associated score. Engagementof a deny element may cause the compliance engine 1442 to decrease anassociated score.

FIG. 15 illustrates the various modules and sub-modules of the userinterface engine 1430. The supervision officer's computing device 110 inFIG. 1 may comprise the user interface engine 1430. The checkup system120 in FIG. 1 may comprise the user interface engine 1430. The userinterface engine 1430 may comprise a parolee database interface 1502, anofficer account database interface 1504, a basic features databaseinterface 1506, a geographic features database interface 1508, anidentification features database interface 1510, a user input engineinterface 1512, a compliance engine interface 1514, and a user interfaceelement generator 1516.

The parolee database interface 1502 may facilitate communication betweenthe user interface engine 1430 and the parolee database 1410 in FIG. 14. The parolee database interface 1502 may facilitate communicationbetween the user interface engine 1430 and the parolee database 1410 viathe network 1450. The parolee database interface 1502 may convert amessage created by the user interface engine 1430 into a formatconsumable by the parolee database 1410. The parolee database interface1502 may convert a message created by the user interface engine 1430into a format transmissible by the network 1450 for ultimate consumptionby the parolee database 1410. The parolee database interface 1502 mayconvert a message received from the parolee database 1410 into a formatconsumable by the user interface engine 1430. The parolee databaseinterface 1502 may convert a message received from the network 1450 andoriginated by the parolee database 1410 into a format consumable by theuser interface engine 1430. As an example, the parolee databaseinterface 1502 may cause queries to be sent to the parolee database 1410and receive query responses from the parolee database 1410. As anexample, the parolee database interface 1502 may cause queries to besent to the parolee database 1410 via the network 1450 and receive queryresponses from the parolee database 1410 via the network 1450. Theparolee database interface 1502 may convert query responses into aformat usable by the user interface engine 1430.

The officer account database interface 1504 may facilitate communicationbetween the user interface engine 1430 and the officer account database1415 in FIG. 14 . The officer account database interface 1504 mayfacilitate communication between the user interface engine 1430 and theofficer account database 1415 via the network 1450. The officer accountdatabase interface 1504 may convert a message created by the userinterface engine 1430 into a format consumable by the officer accountdatabase 1415. The officer account database interface 1504 may convert amessage created by the user interface engine 1430 into a formattransmissible by the network 1450 for ultimate consumption by theofficer account database 1415. The officer account database interface1504 may convert a message received from the officer account database1415 into a format consumable by the user interface engine 1430. Theofficer account database interface 1504 may convert a message receivedfrom the network 1450 and originated by the officer account database1415 into a format consumable by the user interface engine 1430. As anexample, the officer account database interface 1504 may cause queriesto be sent to the officer account database 1415 and receive queryresponses from the officer account database 1415. As an example, theofficer account database interface 1504 may cause queries to be sent tothe officer account database 1415 via the network 1450 and receive queryresponses from the officer account database 1415 via the network 1450.The officer account database interface 1504 may convert query responsesinto a format usable by the user interface engine 1430.

The basic features database interface 1506 may facilitate communicationbetween the user interface engine 1430 and the basic features database1420 in FIG. 14 . The basic features database interface 1506 mayfacilitate communication between the user interface engine 1430 and thebasic features database 1420 via the network 1450. The basic featuresdatabase interface 1506 may convert a message created by the userinterface engine 1430 into a format consumable by the basic featuresdatabase 1420. The basic features database interface 1506 may convert amessage created by the user interface engine 1430 into a formattransmissible by the network 1450 for ultimate consumption by the basicfeatures database 1420. The basic features database interface 1506 mayconvert a message received from the basic features database 1420 into aformat consumable by the user interface engine 1430. The basic featuresdatabase interface 1506 may convert a message received from the network1450 and originated by the basic features database 1420 into a formatconsumable by the user interface engine 1430. As an example, the basicfeatures database interface 1506 may cause queries to be sent to thebasic features database 1420 and receive query responses from the basicfeatures database 1420. As an example, the basic features databaseinterface 1506 may cause queries to be sent to the basic featuresdatabase 1420 via the network 1450 and receive query responses from thebasic features database 1420 via the network 1450. The basic featuresdatabase interface 1506 may convert query responses into a format usableby the user interface engine 1430.

The geographic features database interface 1508 may facilitatecommunication between the user interface engine 1430 and the geographicfeatures database 1422 in FIG. 14 . The geographic features databaseinterface 1508 may facilitate communication between the user interfaceengine 1430 and the geographic features database 1422 via the network1450. The geographic features database interface 1508 may convert amessage created by the user interface engine 1430 into a formatconsumable by the geographic features database 1422. The geographicfeatures database interface 1508 may convert a message created by theuser interface engine 1430 into a format transmissible by the network1450 for ultimate consumption by the geographic features database 1422.The geographic features database interface 1508 may convert a messagereceived from the geographic features database 1422 into a formatconsumable by the user interface engine 1430. The geographic featuresdatabase interface 1508 may convert a message received from the network1450 and originated by the geographic features database 1422 into aformat consumable by the user interface engine 1430. As an example, thegeographic features database interface 1508 may cause queries to be sentto the geographic features database 1422 and receive query responsesfrom the geographic features database 1422. As an example, thegeographic features database interface 1508 may cause queries to be sentto the geographic features database 1422 via the network 1450 andreceive query responses from the geographic features database 1422 viathe network 1450. The geographic features database interface 1508 mayconvert query responses into a format usable by the user interfaceengine 1430.

The identification features database interface 1510 may facilitatecommunication between the user interface engine 1430 and theidentification features database 1424 in FIG. 14 . The identificationfeatures database interface 1510 may facilitate communication betweenthe user interface engine 1430 and the identification features database1424 via the network 1450. The identification features databaseinterface 1510 may convert a message created by the user interfaceengine 1430 into a format consumable by the identification featuresdatabase 1424. The identification features database interface 1510 mayconvert a message created by the user interface engine 1430 into aformat transmissible by the network 1450 for ultimate consumption by theidentification features database 1424. The identification featuresdatabase interface 1510 may convert a message received from theidentification features database 1424 into a format consumable by theuser interface engine 1430. The identification features databaseinterface 1510 may convert a message received from the network 1450 andoriginated by the identification features database 1424 into a formatconsumable by the user interface engine 1430. As an example, theidentification features database interface 1510 may cause queries to besent to the identification features database 1424 and receive queryresponses from the identification features database 1424. As an example,the identification features database interface 1510 may cause queries tobe sent to the identification features database 1424 via the network1450 and receive query responses from the identification featuresdatabase 1424 via the network 1450. The identification features databaseinterface 1510 may convert query responses into a format usable by theuser interface engine 1430.

The user input engine interface 1512 may facilitate communicationbetween the user interface engine 1430 and the user input engine 1440 inFIG. 14 . The user input engine interface 1512 may facilitatecommunication between the user interface engine 1430 and the user inputengine 1440 via the network 1450. The user input engine interface 1512may convert a message received from the user input engine 1440 into aformat consumable by the user interface engine 1430. The user inputengine interface 1512 may convert a message received from the network1450 and originated by the user input engine 1440 into a formatconsumable by the user interface engine 1430. As an example, the userinput engine interface 1512 may receive a signal indicative ofengagement of an element from the user input engine 1440. As an example,the user input engine interface 1512 may receive a signal indicative ofengagement of an element from the user input engine 1440 via the network1450. The user input engine interface 1512 may convert the signalindicative of engagement of an element into a format usable by the userinterface engine 1430.

The compliance engine interface 1514 may facilitate communicationbetween the user interface engine 1430 and the compliance engine 1442 inFIG. 14 . The compliance engine interface 1514 may facilitatecommunication between the user interface engine 1430 and the complianceengine 1442 via the network 1450. The compliance engine interface 1514may convert a message created by the user interface engine 1430 into aformat consumable by the compliance engine 1442. The compliance engineinterface 1514 may convert a message created by the user interfaceengine 1430 into a format transmissible by the network 1450 for ultimateconsumption by the compliance engine 1442. The compliance engineinterface 1514 may convert a message received from the compliance engine1442 into a format consumable by the user interface engine 1430. Thecompliance engine interface 1514 may convert a message received from thenetwork 1450 and originated by the compliance engine 1442 into a formatconsumable by the user interface engine 1430. As an example, thecompliance engine interface 1514 may cause a signal indicative ofattributes associated with a particular entry to be sent to thecompliance engine 1442 and receive a signal indicative of a compliancescore associated with the particular entry from the compliance engine1442. As an example, the compliance engine interface 1514 may cause asignal indicative of attributes associated with a particular entry to besent to the compliance engine 1442 via the network 1450 and receive asignal indicative of a compliance score associated with the particularentry from the compliance engine 1442 via the network 1450. Thecompliance engine interface 1514 may convert the signal of a compliancescore into a format usable by the user interface engine 1430.

The user interface element generator 1516 may create GUI elements thatpopulate a screen. The user interface element generator 1516 may createGUI elements in response to a page load and/or reload. The userinterface element generator 1516 may create GUI elements in response toengagement of an element The created GUI elements may comprise clickableelements, fields for receiving text, image files, etc. The created GUIelements may comprise dynamic elements dependent on current conditions.For example, the user interface element generator 1516 may createclickable elements for check-in entries. For example, the user interfaceelement generator 1516 may create clickable elements with item counts.

FIGS. 16 a-16 b illustrate, in an example embodiment, method 1600 fordisplaying parolee information on a graphical user interface “GUI” of acomputer system for enhanced tracking and reporting. In embodiments, themethod steps or techniques depicted and described herein can beperformed in a processor of the supervision officer's computing device110 in FIG. 1 , the method steps being encoded as processor-executableinstructions in a non-transitory memory of the supervision officer'scomputing device 110. In embodiments, the method steps or techniquesdepicted and described herein can be performed in a processor thecheckup system 120 in FIG. 1 , the method steps being encoded asprocessor-executable instructions in a non-transitory memory of thecheckup system 120. The techniques of FIGS. 16 a-16 b may be implementedin an operating system kernel, in a separate user process, in a librarypackage bound into network applications, on a specially constructedmachine, on an application-specific integrated circuit (ASIC), or afield programmable gate array (FPGA).

At step 1602, an electronic signal associated with an officer accountmay be received. The electronic signal may be associated with a firstset of user interface elements identifying metrics associated with atleast one parolee. The first set of user interface elements may comprisea first section of user interface elements that are associated withbasic features. The first set of user interface elements may comprise asecond section of user interface elements that are associated withgeographic features. The first set of user interface elements maycomprise a third section of user interface elements that are associatedwith identification features. The basic features may comprise one ormore of a check-in event, an agenda event, a curfew event, and atime-line event. The user interface 500 in FIG. 5 may comprise the firstset of user interface elements.

At step 1604, historical data associated with at least one paroleeaccount that is associated with the officer account may be received by aprocessor. The historical data may comprise at least one of a name, acontact address, a profile picture, a contact number, a previouscheck-in expected time, a previous check-in expected location, aprevious check-in actual time, a previous check-in actual location, anda previous check-in photograph.

At step 1606, a second set of user interface elements comprising aplurality of sections may be automatically displayed. The second set ofuser interface elements may display parolee information associated withthe at least one parolee account that is associated with the officeraccount. The user interface 1900 a in FIG. 19 a may comprise the secondset of user interface elements.

At step 1608, user check-in data may be displayed in a first section ofthe second set of user interface elements. The user check-in data maycomprise one or more entries. Each entry may be associated with aparolee check-in event. A score may be associated with each entry in theuser check-in data. The score associated with an entry may be at leastpartially affected by a comparison of an actual check-in time associatedwith the entry with an expected check-in time associated with the entry.The score associated with an entry may be at least partially affected bya comparison of an actual check-in location associated with the entrywith an expected check-in location associated with the entry. The scoreassociated with an entry may be at least partially affected by acomparison of actual verification information associated with the entrywith an expected verification information associated with the entry.

At step 1610, user location data may be displayed in a second section ofthe second set of user interface elements. The user location data maycomprise a map associated with geolocation data associated with a deviceassociated with the at least one parolee account.

At step 1612, user interface elements to approve or deny pendingcheck-ins may be displayed in a third section of the second set of userinterface elements. The third section of the second set of userinterface elements may comprise aggregated data. Engagement of the userinterface element to approve a pending check-in may cause a scoreassociated with the entry associated with the pending check-in to rise.Engagement of the user interface element to deny a pending check-in maycause at least one of a score associated with the entry associated withthe pending check-in to lower and a field for receiving a reason fordenial to be prompted.

Optionally, a GUI overlay may be displayed over at least a portion ofthe second section of the second set of user interface elements. Theportion of the second section of the second set of user interfaceelements may comprise a map associated with a physical location of auser device associated with the at least one parolee account. The GUIoverlay may be a first color if a threshold number of requirements aremet, and a second color if the threshold number of requirements are notmet. The GUI overlay may comprise green if the threshold number ofrequirements are met. The GUI overlay may comprise red if the thresholdnumber of requirements are not met. The threshold number of requirementsmay comprise an actual check-in time within a threshold timeframe of anexpected check-in time. The threshold number of requirements maycomprise an actual check-in location within a threshold distance of anexpected check-in location. The threshold number of requirements maycomprise actual verification information within a threshold proximity ofexpected verification information. The verification information maycomprise at least one of a signature, a picture of the parolee takencontemporaneously, a picture of a location taken contemporaneously, etc.

FIG. 17 illustrates a graphical user interface (GUI) 1700 for aregistration process for monitoring a parolee. The GUI 1700 may comprisea screen a parolee sees when the parolee first executes an applicationembodying the systems and/or methods described herein. The GUI 1700 maycomprise input fields 1702 to receive a digital code and an engageableelement (e.g., button, etc.) 1704 to move to a next screen. The digitalcode may be specific to the parolee. Engagement of the engageableelement 1704 may cause a device identifier (e.g., media access control(MAC) address, phone number, device identification (ID), etc.)associated with a device used to access the GUI 1700 to be associatedwith a parolee associated with the digital code entered into the inputfields 1702.

FIG. 18 illustrates a GUI for monitoring a parolee. The GUI may comprisea screen 1800. The screen 1800 may be what an officer sees when anofficer logs into an application in accordance with the systems and/ormethods disclosed herein. The screen 1800 may comprise an event section1802 comprising entries 1804, 1806, 1808, 1810 corresponding to events.The screen 1800 may comprise various filtering and sorting options thatdictate the entries 1804, 1806, 1808, 1810 shown in the event section1802. For example, the events may be filtered by a date range, aparolee, a parolee response to the event, an event attribute, etc. Thescreen 1800 may comprise tabs to switch between various types of events.For example, a tab may correspond to check-in events, curfew events,check-in near events, manual check-in events, agenda events, locationrequest events, etc. In an embodiment, when a particular tab isselected, entries in the event section 1802 correspond to the selectedtab. For example, when the check-in tab is selected, the entries 1804,1806, 1808, 1810 in the event section 1802 may be check-in events. Eachentry may comprise event details. For example, check-in entries 1804,1806, 1808, 1810 may comprise a parolee name, a check-in date, acheck-in time, a score, etc. Each of the entries 1804, 1806, 1808, 1810may be engageable (e.g., pressable, clickable, etc.).

FIGS. 19 a-19 b illustrate a GUI for monitoring a parolee. The GUI maycomprise screen 1900 a and 1900 b. Screen 1900 a may be what an officersees when an officer engages (e.g., presses, clicks, etc.) entry 1804 inscreen 1800 in FIG. 18 . Screen 1900 a may comprise an event section1902, which is similar to the event section 1802 in FIG. 18 , a detailsection 1904, and a location section 1906. The detail section 1904 maycomprise a user interface element to accept a pending check-in 1908, auser interface element to deny a pending check-in 1910, a field toreceive a reason for denying a pending check-in 1912, aggregated data,etc. Engagement of the user interface element to accept a pendingcheck-in 1908 may cause a score associated with the pending check-in togo up. Engagement of the user interface element to deny a pendingcheck-in 1910 may cause a score associated with the pending check-in togo down. Aggregated data may comprise a date when a check-in request wassent, a time when a check-in request was sent, a date when a check-inrequest was responded to, a time when a check-in request was respondedto, a score, a rating for punctuality of a check-in, a rating foridentity associated with a check-in, a rating for a vicinity of acheck-in, a rating for a location of a check-in, alerts, etc.

The location section 1906 may comprise a map showing a location of adevice at the time of a check-in associated with the engaged (e.g.,pressed, clicked, etc.) entry 1804. The map may comprise a color-coatedoverlay that indicates an appropriateness of the location. For example,the map may comprise a green overlay when the location of a check-in isappropriate (e.g., within approved boundaries, not from a locationdeemed inappropriate, etc.). As another example, the map may comprise ared overlay when the location of a check-in is inappropriate (e.g.,outside approved boundaries, in or within range of a location deemedinappropriate, etc.). The location section 1906 may comprise a userinterface element to allow the officer to track a device associated witha parolee.

Screen 1900 b may be what an officer sees when an officer scrolls downfrom screen 1900 b. In some displays and/or settings, screens 1900 a and1900 b may be displayed at the same time. Screen 1900 b may compriseverification information. Screen 1900 b may comprise a profile photo1920. Screen 1900 b may comprise a photo taken at a check-in associatedwith engaged entry 1804. Screen 1900 b may comprise a digital signature1924. The digital signature 1924 may comprise identifying information,such as first name, last name, address, phone number, etc.

Additional Considerations

As used herein any reference to “one embodiment” or “an embodiment”means that a particular element, feature, structure, or characteristicdescribed in connection with the embodiment is included in at least oneembodiment. The appearances of the phrase “in one embodiment” in variousplaces in the specification are not necessarily all referring to thesame embodiment.

Some embodiments may be described using the expression “coupled” and“connected” along with their derivatives. For example, some embodimentsmay be described using the term “coupled” to indicate that two or moreelements are in direct physical or electrical contact. The term“coupled,” however, may also mean that two or more elements are not indirect contact with each other, but yet still co-operate or interactwith each other. The embodiments are not limited in this context.

As used herein, the terms “comprises,” “comprising,” “includes,”“including,” “has,” “having” or any other variation thereof, areintended to cover a non-exclusive inclusion. For example, a process,method, article, or apparatus that comprises a list of elements is notnecessarily limited to only those elements but may include otherelements not expressly listed or inherent to such process, method,article, or apparatus. Further, unless expressly stated to the contrary,“or” refers to an inclusive or and not to an exclusive or. For example,a condition A or B is satisfied by any one of the following: A is true(or present) and Bis false (or not present), A is false (or not present)and Bis true (or present), and both A and B are true (or present).

In addition, use of the “a” or “an” are employed to describe elementsand components of the embodiments herein. This is done merely forconvenience and to give a general sense of the invention. Thisdescription should be read to include one or at least one and thesingular also includes the plural unless it is obvious that it is meantotherwise.

Upon reading this disclosure, those of skill in the art will appreciatestill additional alternative structural and functional designs for asystem and a process for creating an interactive message through thedisclosed principles herein. Thus, while particular embodiments andapplications have been illustrated and described, it is to be understoodthat the disclosed embodiments are not limited to the preciseconstruction and components disclosed herein. Various apparentmodifications, changes and variations may be made in the arrangement,operation and details of the method and apparatus disclosed hereinwithout departing from the spirit and scope defined in the appendedclaims.

What is claimed is:
 1. A computer implemented method for displayingparolee information on a graphical user interface “GUI” of a computersystem for enhanced tracking and reporting, the computer implementedmethod comprising: receiving an electronic signal associated with anofficer account, wherein the electronic signal is associated with afirst set of user interface elements identifying metrics associated withat least one parolee, wherein the first set of user interface elementscomprises a first section of user interface elements that are associatedwith basic features, further wherein the first set of user interfaceelements comprises a second section of user interface elements that areassociated with geographic features, further wherein, the first set ofuser interface elements comprises a third section of user interfaceelements that are associated with identification features; receiving, bya processor, historical data associated with at least one paroleeaccount that is associated with the officer account; automaticallydisplaying a second set of user interface elements comprising aplurality of sections, the second set of user interface elementsdisplaying parolee information associated with the at least one paroleeaccount that is associated with the officer account; displaying usercheck-in data in a first section of the second set of user interfaceelements; displaying user location data in a second section of thesecond set of user interface elements; and displaying user interfaceelements to approve or deny pending check-ins in a third section of thesecond set of user interface elements.
 2. The computer implementedmethod of claim 1, further comprising displaying a GUI overlay over atleast a portion of the second section of the second set of userinterface elements.
 3. The computer implemented method of claim 2,wherein the portion of the second section of the second set of userinterface elements comprises a map associated with a physical locationof a user device associated with the at least one parolee account. 4.The computer implemented method of claim 2, wherein the GUI overlay is afirst color if a threshold number of requirements are met, and a secondcolor if the threshold number of requirements are not met.
 5. Thecomputer implemented method of claim 4, wherein the GUI overlaycomprises green if the threshold number of requirements are met.
 6. Thecomputer implemented method of claim 4, wherein the GUI overlaycomprises red if the threshold number of requirements are not met. 7.The computer implemented method of claim 4, wherein the threshold numberof requirements comprises an actual check-in time within a thresholdtimeframe of an expected check-in time.
 8. The computer implementedmethod of claim 4, wherein the threshold number of requirementscomprises an actual check-in location within a threshold distance of anexpected check-in location.
 9. The computer implemented method of claim4, wherein the threshold number of requirements comprises actualverification information within a threshold proximity of expectedverification information.
 10. The computer implemented method of claim9, wherein the verification information comprises at least one of asignature, a picture of the parolee taken contemporaneously, and apicture of a location taken contemporaneously.
 11. The computerimplemented method of claim 1, wherein the historical data comprises atleast one of a name, a contact address, a profile picture, a contactnumber, a previous check-in expected time, a previous check-in expectedlocation, a previous check-in actual time, a previous check-in actuallocation, and a previous check-in photograph.
 12. The computerimplemented method of claim 1, wherein the third section of the secondset of user interface elements comprises aggregated data.
 13. Thecomputer implemented method of claim 1, wherein the basic featurescomprise one or more of a check-in event, an agenda event, a curfewevent, and a time-line event.
 14. The computer implemented method ofclaim 1, wherein the user check-in data comprises one or more entries,and wherein each entry is associated with a parolee check-in event. 15.The computer implemented method of claim 14, wherein a score isassociated with each entry in the user check-in data.
 16. The computerimplemented method of claim 15, wherein engagement of the user interfaceelement to approve a pending check-in causes a score associated with theentry associated with the pending check-in to rise.
 17. The computerimplemented method of claim 15, wherein engagement of the user interfaceelement to deny a pending check-in causes at least one of a scoreassociated with the entry associated with the pending check-in to lowerand a field for receiving a reason for denial to be prompted.
 18. Thecomputer implemented method of claim 15, wherein the score associatedwith an entry is at least partially affected by a comparison of anactual check-in time associated with the entry with an expected check-intime associated with the entry.
 19. The computer implemented method ofclaim 15, wherein the score associated with an entry is at leastpartially affected by a comparison of an actual check-in locationassociated with the entry with an expected check-in location associatedwith the entry.
 20. The computer implemented method of claim 15, whereinthe score associated with an entry is at least partially affected by acomparison of actual verification information associated with the entrywith an expected verification information associated with the entry.